iT邦幫忙

2024 iThome 鐵人賽

DAY 7
0
佛心分享-叢林中的 PM

那些年,我們一起經歷的專案失敗系列 第 7

「專案管理」要怎麼進化?

  • 分享至 

  • xImage
  •  

這裡又要再形名辯證一次。
這個「要怎麼進化」的專案管理,是指技巧與學科。

「這兩個東西的屬性好像差距有點遠?有辦法一起討論嗎?」

有的。如果看懂我的主張,會發現必須一起討論。

前面說過:為了全球化,專案管理會使用「對全體都不友善不直覺的專案管理軟體」來控管並彙整大家的工作進度,因為「我對各個區域的工作同事是一視同仁的不友善不直覺,所以大家就都別抱怨了!」。

這個不友善不直覺主要是侷限在UI/UX上。

專案管理軟體其實可以分成兩大類,一是瀑布流式介面,二是表單式介面。
但不管是哪一種,我對他們的評價都不高(O.S.:「這種東西大多連屎都不如」),原因在於:它服務的核心對象並不是專案團隊,而是僅僅只有專案管理階層而已!

它其實是「專案管理(學科與產業)關切的大多是自己的利益」的共犯結構的一環。
絕大多數的專案管理者(身兼團隊領導者經營者)對專案沒有興趣,對商品也沒有任何進一步的概念與想法,對管理更是毫無熱情,整個團隊成員在他們眼中只是一張又一張的魔法衛生紙,耐用、可多次重復使用、拋棄時無負擔、還會自己抽出來後把精液屎尿擦乾淨、只留下一個乾淨的工作成果任由自己享受成果(不管是端上去跟上級邀功、還是等著專案能夠為自己帶來收益),自己只需要時時注意「哪幾張衛生紙該抱著殺伐果斷的英明神武處理掉」即可。

假設我們先只討論理想的專案管理吧!
客戶不會因為時程到了、沒有交出百分之百如當初預期承諾的產品,就拒絕給錢,全體業界也不會看到這次專案的執行結果就毅然決然的將專案團隊打入「不可往來」冷宮中,專案團隊成員不會有管理者大頭症或「反正我就領薪水過日子、專長是巴結管理者和逢迎上意」的小人物心態,大家都是思考正面、態度積極、願意互相合作互相成就的理性生物,那這類軟體的整體功能應該如下...

專案建立後可以設定多個里程碑和工作項目大類別,里程碑可以連結多個工作項目,讓工作項目的進度成果來判斷里程碑是否完成,里程碑的期限是以「所需總工作項目需要投入的工作量(工時)和參與工作項目的人員數目來程式自動化計算」。
工具的首頁應該要要使用瀑布流以優先呈現「團隊成員目前手中的子任務與關聯的工作項目」,而不是「大家目前的進度」。
工作項目的「時程」必須是彈性的。假設開工時預定N小時完成,新增子任務或完成子任務時應該要能設定「是否需要額外的時間」,如果設定為「不需要」或「額外需時為0」,則整個工作項目預計完成的工作時間依舊是N,否則如果不為0、而是M,則工作項目預計完成的工作時間就是N+M。
工作項目與工作項目之間,要能共用同一個子任務,也就是說「某些子任務的完成可以同時推動多個工作項目的進行」。但子任務創建或完成的當下可能只以設定給一個工作項目,在未來可以將子任務連結到其他工作項目。
某些工作項目並沒有「設計稿」,而是種抽象的概念與目標,例如功能核心底層的連線機制,或是某種非常有特色的、為專案而設計並在專案內被廣泛使用的視覺元件。

這些設計的理念在於:專案管理應該要以成員間的溝通交流為優先,(反映意見或提交資訊給管理者或其他參與者為其次,)而不是決定專案交件時程後,管理者看著專案軟體上每個人的工作進度來決定要拿老二抽打誰,美其名是管理權威,但其實就是用恐懼痛苦來讓專案動起來。
對!我在暗示:多數的專案管理軟體最終推出來的功能與樣貌都是以「讓管理者方便決定拿老二抽打誰」為核心思維。
明明大家多多少少也都聽過「專案的樣貌在規劃時應該要以不需要管理、讓成員可以自然而然地進行團隊合作並完成產品生產,(因為大家都是思考正面、態度積極、願意互相合作互相成就的理性生物)」這樣的概念,但很多組織天生就營養不良,他們的創始者或現在的經營者只是個缺乏歷練與專業修養、同時又找不到自己的人生目標重心、但又自我膨脹過頭的資本家階級,先不管他們為什麼要創立一個用於生產的營利組織,也不管他們是成立前、還是成立後才發現自己根本管不動生產專案所以決定另外聘請專案管理人,反正這個請來的專案管理人的管理風格會反映出缺乏歷練與專業修養、同時又找不到自己的人生目標重心、但又自我膨脹過頭的特質,而專案管理軟體就會迎合這樣的特質。

「看著我(專案管理軟體),我會幫助你找出下一個該用老二打一頓後驅逐的員工。」

從某種角度來看,在沒有相對科技或工具的輔助下,管理專案的不二法門其實就是要指派一個人,讓這個人維持極度自律且精練的工作習慣去日復一日的查詢員工工作進度表現與意見,同時不停的進行各種協調、討論、思考,(專案管理技能有一部份就是在幫助管理人建立一個這樣的工作習慣。)
但這是在沒有相對科技或工具的輔助下,如果有相對的科技或工具呢?
例如專案軟體能夠讓管理者觀察到哪些工程師的工作成果具有很高的復用性?哪些工程師耗時的元件?...甚至可以主動判斷並作出統計結果。

對,我在說AI。

如果專案管理軟體設計的目的並不只是滿足於「以及少量的資訊與標準去監控專案的進度」,而是會去「更深入的搜集執行成效以外」的各種資訊,集合這些資訊後,專案軟體能夠進一步從統計資料中發掘各種資訊間的關聯,那即使沒有專案管理技能/工作習慣的一般管理階層是否也能做出專案管理上的判斷呢?

那,到時候我們還需要專案管理人嗎?

專案管理的未來:不再需要專案管理,將專案管理也納入企業生產時,應該要用自動化取代的項目之一。

(乾杯!一定一堆人其實看不懂我到底在講什麼。)


上一篇
換個方向想想特斯拉該怎麼做
下一篇
把愚蠢複製貼上三次:遠傳、中華、台灣大
系列文
那些年,我們一起經歷的專案失敗16
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言